home *** CD-ROM | disk | FTP | other *** search
/ Miggybyte 4 / Miggybyte 4.adf / DOCS / MB_7.txt < prev    next >
Text File  |  1996-02-14  |  12KB  |  237 lines

  1.  
  2.      ===== Dr. Hepler on Hombre [he was the one in charge of it]=====
  3.  
  4.  
  5. I have seen a lot of discussion over the past months on the pros and cons
  6. of  various RISC processors and the future of the Amiga.  Since it was my
  7. responsibility  to make some of these decisions in the past, and now that
  8. Escom  has  announced their decision, I thought that some of you may find
  9. it  interesting  to hear some of my views as I remember them and get some
  10. insight  into  how  decisions  like  this  are made...  or at least how I
  11. approached  things.   From  what  I  have seen on the net, many folks out
  12. there have no clue as to how things like this are really done :-)
  13.  
  14. Remember  that  much  of this happened well over two years ago...  and my
  15. memory  is not as good as it perhaps should be...  Take all of this to be
  16. my  opinion....   you  may disagree with whatever you like...  First, you
  17. have  to  put  this into context.  In order to make a decision like this,
  18. one  has  to have a strategic plan for the future.  This plan then drives
  19. the decision process.  As such I had some ground rules to start with:
  20.  
  21. a.  Only one chip set would be developed...  We only had enough R&D money
  22. for  one...  so it had to address the low-end (game console, set-top-box)
  23. to  high end (work-station, A4000 style machine)...  The requirements for
  24. low-end systems are so different than those of high-end systems that this
  25. is quite difficult...
  26.  
  27. b.  It had to be capable of supporting Windows-NT sometime in the future.
  28. Amiga-DOS  would  be  ported (at least the micro-kernel for game systems,
  29. set-top-boxes)...   the  rest later (for low-end systems)....  but it was
  30. felt (at the time) that NT would be the emerging OS...  and compatibility
  31. would be necessary for market acceptance outside of the traditional Amiga
  32. market.   Having  support  for  a  "more  main stream" OS would have made
  33. getting  main  stream  applications  ported to the machine *much* easier.
  34. This  ground  rule  meant  that  we  wanted  a platform which had some NT
  35. porting  activity  at  least started...  It also had some implications on
  36. the type of memory management needed.  No flames please.
  37.  
  38. c.  I knew that we could not support a *complete* line of products within
  39. Commodore with our resources...
  40.  
  41. But  I  felt  that  we could not have a product line which did not have a
  42. link  of some kind to more powerful machines like those used in business.
  43. Most  people  like  to  have  something  at  home  which  is  in some way
  44. compatible  with  what  they  use at work.  I wanted to select a platform
  45. which  gave Hombre users a growth path for the future.  We wanted to have
  46. a  strategic  partnership  with  a  company  which  had a *complementary*
  47. product line...  and perhaps cross-promote, etc.
  48.  
  49. d.   I  wanted to be able to include the integer core of the processor on
  50. one  of  the  Hombre  chips.   We  also  wanted  to  be able to add a few
  51. instructions to aid in graphics setup, etc.
  52.  
  53. e.  I was targeting a 0.6 micron, 3-level metal CMOS process.
  54.  
  55. Of  course  cost was a major concern.  I have seen many people on the net
  56. discuss  RISC  chips  *without* considering the cost as it applies to the
  57. overall system.  In order to build a system like the A1200, hit the price
  58. point  that  we  wanted, and make a profit, the CPU chip, custom graphics
  59. chips,  etc,  have  to cost about $20 (total!!).  Many folks forget about
  60. all  the  other  costs  involved  in  producing  a  product.   This alone
  61. eliminates  many  of  the  candidates that some have proposed and cheered
  62. for...   Our  cost  objective  for  the Hombre chip set was a little more
  63. liberal than this since I was integrating more onto the chips...  but the
  64. cost  target was not much more!!  Certainly not some of the prices I have
  65. seen  bantered  about some of the groups here.  Remember, we wanted to be
  66. able to put this into a game console or set-top box.  You can't spend 1/3
  67. of  the  retail price of the product on the CPU chip!!!  I looked at many
  68. (almost all the commercially available) architectures (my favorite from a
  69. purely  computer  architect  (my  primary  training)  viewpoint  was  the
  70. MC88100)...   and  narrowed  down  to three:  MIPS, PowerPC, and PA-RISC.
  71. Lew E.  and I talked to all the companies involved:
  72.  
  73.  
  74. MIPS:
  75.  
  76. MIPS  was  interesting  because their parent company is Silicon Graphics.
  77. Wouldn't  it  be  nice  to  have a strategic partnership with the premier
  78. high-end   graphics   company!!!    We  could  have  built  the  low  end
  79. "home-version" of their machine, made great games, etc.  Lew and I talked
  80. with one of the founders and he asked lots of questions, etc., but didn't
  81. sound  too  interested...  The 4200 series MIPS chips where too expensive
  82. and  they didn't seem too interested in making any changes for us...  The
  83. R3000  series  was  in  the  right  cost  area,  but  was  not viable for
  84. Windows/NT.   As  I  said  above,  we  felt at that time that it would be
  85. important for this chip set to be able to support NT in the future.
  86.  
  87. We  dropped  them  from  the  list  and found out shortly thereafter that
  88. SGI/MIPS had signed an agreement with Nintendo for their next generation.
  89. It  was  obvious then that they knew when they had talked to us that they
  90. were  in  discussions with Nintendo...  It must have been interesting for
  91. them...
  92.  
  93. By the way, at that point, we were 9 months to a year ahead of them...
  94.  
  95.  
  96. PowerPC:
  97.  
  98. Motorola  talked  to  us about PowerPC (IBM may have come in too, I don't
  99. remember)...   We  had  a  good  working  relationship with Motorola as a
  100. vendor.   I  had  earlier done a study to integrate AA type functionality
  101. onto a die with an MC680x0 core.
  102.  
  103. I had a number of problems with the PowerPC:
  104.  
  105. a.   An  early  version  of the instruction set documents (received under
  106. NDA)  caused  me  to  have  a  real  concern about using this part in our
  107. product line.  Lew E.  agreed.  I can't really discuss this any further.
  108.  
  109. b.   They  were  unwilling  to  do a full-custom version for us (with our
  110. graphics enhancements) and their time-table for core-versions was too far
  111. out.
  112.  
  113. c.   There  was  no  good  strategic relationship from a systems point of
  114. view.    It   seemed   unreasonable   to   approach   Apple:   they  were
  115. competitors...   their  line was not complementary.  The same was true of
  116. IBM, and Motorola did not have a strong systems presence.
  117.  
  118. d.   A  small,  embedded version of PowerPC (the one that we could afford
  119. for  the  low end...  (which was being developed for use in automobiles))
  120. did  not  have a memory management option...  something required for both
  121. Windows/NT and set-top-boxes.
  122.  
  123. e.   The  core  version that they did promise would have required that we
  124. add  our  logic  as  standard  cells.   A standard cell implementation of
  125. Hombre  would  have  been  far  too  large - and therefore expensive.  We
  126. intended  to  do  a  custom  layout of the datapaths involved and merging
  127. these datapaths with their logic was viewed as a problem...
  128.  
  129. f.   I  felt  the  instruction set had some problems...  for example, the
  130. only  way to get information between integer registers and floating point
  131. registers was through memory!
  132.  
  133.  
  134. PA-RISC:
  135.  
  136. HP presented the PA-RISC.  We had a rather good working relationship with
  137. HP.  They had fab'd the LISA chips and had done all the foundary work for
  138. the AAA project.
  139.  
  140. The PA-RISC:
  141.  
  142. a.   It  had  one  of  the  most  powerful  RISC  instruction  sets I had
  143. evaluated.   It  created  very  dense code (for a RISC) - and the dynamic
  144. cycle  count  was  very  good.   It  also  had an instruction (SFU) which
  145. allowed customization without interfering with compatibility...
  146.  
  147. I  had  defined some instructions which would aid in the 3D graphics that
  148. had been planned for Hombre.
  149.  
  150. b.   Other PA-RISC partners had already shown that a low-cost version was
  151. feasible.
  152.  
  153. c.   HP  had  a  totally  complementary  product  line  -  their  low end
  154. workstations were more powerful than our high end Amigas.
  155.  
  156. d.   HP  seemed  interested  in  the  current  Amiga chipset for use in a
  157. set-top-box  and  seemed  interested  in  the  Hombre  chipset for a next
  158. generation  set-top-box.  This made good business sense and allowed us to
  159. propose a rather nice agreement...  By the way, Commodore died before the
  160. agreement could be signed.
  161.  
  162. e.   HP  was  willing  to  license  Commodore to design and build our own
  163. version  of a core for use in Hombre.  I had designed the integer core of
  164. the CPU and showed them (HP) simulations of it (to prove our competence).
  165. (This  was  done  with  only  the  instruction  set reference manual - no
  166. proprietary  information  or  design  was received from HP.) I'm not sure
  167. that  the license was really necessary...  I had in effect created my own
  168. implmentation  of  a  published instruction set...  Many others have done
  169. this  with  other  instruction  sets without a license...  but having the
  170. license  would  have  been  nice  and  their  cooperation would have been
  171. useful.
  172.  
  173. f.   While  the  HP  chips  were  not available on the open market, other
  174. partners  of theirs did have chips that could be put into systems.  These
  175. other  processors  would  have been used as the external processor on the
  176. larger systems I proposed.
  177.  
  178. The  architecture that was proposed by me (and approved by Lew) was a two
  179. chip  set.   One  chip was a video buffer for the most part...  the other
  180. chip held the internal cpu, blitter, and other goodies, etc.  By the way,
  181. the internal datapath was a full 64 bits.  There were two bonding options
  182. to  get  a  lower  costing  32 bit memory interface for game-consoles and
  183. set-top  boxes,  and  a  slightly more expensive 64 bit option for higher
  184. ended  systems  (VLSI  packaging  costs  can be significant for large pin
  185. counts).   The wider memory was not really necessary for the very low end
  186. systems  which  only had to produce NTSC or PAL level video, and was less
  187. expensive...   Low  end  products  used  the  internal processor as *the*
  188. processor.    Higher  end  systems  used  the  internal  processor  as  a
  189. peripheral/graphics  processor.  While it made a lot of sense to have the
  190. external  processor  be  a  PA-RISC  processor,  there  was  nothing that
  191. required it.
  192.  
  193. The  architecture  also  made  use  of  the  PCI  bus.  Again, on low end
  194. systems, the PCI held peripherals for use by the internal processor.  For
  195. higher  end  systems  this  was also true.  But the PCI bus could also be
  196. turned  around...  this allowed the chip set to be used *as a peripheral*
  197. to  any PCI based system.  This was intended to allow this chip set to be
  198. used  as  a  peripheral  to  PCs.   Also,  this  was the "link" to the HP
  199. workstations.  It was hoped that this chip set could be configured onto a
  200. PCI  card  for  incorporation  into  HP workstations...  This would allow
  201. software which ran on our systems run on HP workstations...
  202.  
  203. I  had  written  a  simulation of the CPU, enhanced blitter/renderer, and
  204. memory  interface  in  C  to  test  instruction  sequences  and rendering
  205. performance.   (The  simulation  even  had  a  Tcl/Tk  GUI!).  I had also
  206. modelled  many  of  the  blocks  in  M (a behavioral simulation/synthesis
  207. language - similar in function to VHDL or Verilog).  Some of the datapath
  208. had  started  transistor  level design...  Then things fell apart and the
  209. couple  of  people I had just gotten assigned to work on this either quit
  210. to  take  other jobs or were laid-off...  Remember before you flame me...
  211. Most  of  this  happened  over  two  years ago.  Had we remained solvent,
  212. gotten  the resources that had been promised and remained on our original
  213. schedule, we would have had first silicon at the beginning of 1995!
  214.  
  215. I believe that given the strategy, ground rules, information at the time,
  216. etc., I made the correct decision.  I don't know what strategy Escom has,
  217. what  their ground rules were or how they made their decision, so I can't
  218. comment on their selection...
  219.  
  220. I  hope this insight has been interesting and educational....  :-) Again,
  221. all  of  the  above  is  my  opinion...  not to be taken as the policy or
  222. beliefs of my employers, etc.
  223.  
  224. Dr. Edward L. Hepler     Former:
  225. President,                Director of VLSI and System Architecture VLSI
  226.  
  227. Concepts, Inc.       Architect of Hombre, Designer of Andrea (AAA)
  228.   VLSI Architecture,      Commodore
  229.    Design, CAD
  230.  
  231. Adjuct  Prof.   ECE  Department,  Villanova  University ECE-8445 Graduate
  232. level Advanced Computer Architecture ECE-8460 Graduate level Introduction
  233. to VLSI Design elh@ece.vill.edu
  234.  
  235. END
  236. ---
  237.